1. Field of the Invention
The present invention relates to a system and method for private and secure transactions and more particularly to a system and method for providing private and secure buy/sell or withdraw/deposit transaction environment within financial institutions and at merchants/sellers/vendors transaction-processing systems.
2. Description of the Related Art
Basic financial transactions including buy/sell and withdraw/deposit, have always required security to protect the financial account holder, the financial institution where the account resides, and a merchant/seller/vendor or other party at the point of sale from identity theft and fraudulent transactions. Due to wide spread use of computer networks and electronic commerce as a new medium to perform transactions, new requirements to maintain validity and integrity of financial transactions are arising. There are companies gathering, sorting, researching and selling for profit consumers' private personal information acquired during financial transactions. It would be advantageous to provide an efficient system and method to protect customers' privacy during financial transactions. Another new requirement is associated with the fact that hackers and intruders getting an illegal access to the computer network can compromise financial transactions. This aspect of transactions' security is addressed in U.S. Pat. No. 6,092,202 to Veil et al.
Throughout the entire history of financial transactions, privacy and security were addressed by the best contemporary technologies. Since the onset of the computer network era, computer power, relational databases, software environments and communication lines have been used by financial institutions for security and privacy functions. Banks, then credit card companies and eventually brokerage companies and other financial institutions have used them to perform authentication, authorization and accounting, referred to as AAA, at their back offices during financial transactions.
Financial transactions with credit cards suffer significant losses due to weaknesses in implementing the authentication stage of financial transaction. A party at the point of sale compares human signatures visually on a card (if there is any) and on a selling slip. This operation is error prone when identifying faked signatures in a case of fraudulent actions. If a financial account holder loses an unsigned credit card it is easy to fake signatures as one can place any signature on a card before requesting a financial transaction. Another typical malfunction at the authentication stage of financial transaction occurs when someone gets a credit card account number and a copy of the card owner's signature. This enables fraud even with non-stolen credit cards. Another example where financial institutions incur losses is caused by financial account holders, when they change their minds after concluding a financial transaction. A financial account holder can repudiate the financial transaction by claiming that somebody transacted in their place.
These examples show that there is a real and substantial need for an improved financial transaction architecture at the authentication stage of financial transaction. The fact that mistakes in authenticating non-real credit card owners followed by successful authorization and accounting sessions at financial institution back offices illustrate another weakness of the financial transaction architecture. Authorization and accounting stages are de-coupled from the actual financial account holder, while the authentication stages are de-coupled from financial institution back office computers.
Though credit cards have been used as a financial transaction instruments since the beginning of electronic commerce, there is number of issues in architecture that have become apparent. For instance, credit card data, a social security number, a card holder name, phone, address etc., while transferred through the Internet, are not absolutely secure and can fall into “wrong hands” due to communication channel leaks. It is obvious that while high speed data flow through the Internet or other communication channels is a big advantage for financial transactions, insufficient data security makes it highly desirable to alter the financial transaction architecture to avoid potential data leaks on communication lines (Internet and non-Internet as well).
Another issue jeopardizing financial transactions in electronic commerce is weakness of the authorization stage of financial transactions with credit cards. Neither the authorization stage nor the accounting stage are actively controlled and timed by financial account holders. Numbers of non-requested sell transactions may happen before a financial account holder regains control on his/her account. U.S. Pat. No. 5,485,510 to Colbert and U.S. Pat. No. 6,052,675 to Checchio disclosed attempts to improve the authorization stage of financial transactions in order to enhance financial transaction security. The Colbert patent proposed to alter financial transactions by authorizing a financial account holder before he/she applies to a merchant (a vendor). Information supplied to financial institution back office includes a credit card account number, a secret PIN and merchant/financial transaction specific information (at least, merchant ID number and financial transaction amount). Then the merchant is given only the authorization code, while the card number and the PIN remain unknown to the merchant or anybody, if the card is lost or stolen. Similar architecture is offered in the Checchio patent, except a merchant does not get any authorization code, but rather a credit card account number. Since the financial transaction is pre-authorized in this case, a merchant sends into the financial institution back office a credit card account number and merchant/financial transaction specific information, which is compared with data given by the financial account holder during the pre-authorization stage. Neither a merchant nor anybody can use the card without knowing a secret PIN, if it is lost or stolen.
Though both patents allow improve security against fraudulent usage of credit cards for certain types of transactions, there are limitations to be addressed. Both patents are centered on phone lines, when communicating to financial institution back offices. Frequent usage of a pair of static numbers over phone lines is insecure due to leaks at the line entries and on the lines themselves. This issue gets aggravated, if one would like to replace phone lines by wireless or the Internet communication lines. Another weakness common to both patents is lack of a system and/or method as to how the financial institution back office is supposed to handle proposed architectural changes for mass financial transactions. Financial transaction architectures ought to cover financial account holders, financial institutions and a party at the point of sale in a mutually dependent way. A necessity to have prior to the authorization stage knowledge of a party at the point of sale and other financial transaction specifics is an additional limitation in both proposed innovations. That narrows down types of possible financial transactions and locations, in which they can be performed from.
There is a public concern that financial transactions with credit cards either in electronic commerce channels or in other traditional channels could lead to private personal consumers' information being accessed, monitored, tracked, stolen and fraudulently used or sold for profit often without the consumers' approval. Privacy related problems are exacerbated with the advanced Internet related technologies due to the ease with which information can be collected, processed and combined with other information.
It is not only financial transactions with credit cards which raise numerous privacy issues. Even during standard withdraw/deposit financial transactions at a bank, a financial account holder would not always like a bank teller to have access to his/her private personal information file. It would be beneficial if a financial account holder could decide whether this privilege should be given to the bank teller. More often than not, withdraw/deposit financial transactions at a bank require financial account holder identification documents to be revealed, which can be viewed as a certain privacy related inconvenience justified by the current state of the authentication architecture during financial transaction.
FIG. 1A illustrates a block diagram of a conventional system for performing withdraw/deposit transactions. In order to perform financial transactions, a legal adult 101 (or a legal business) is supposed to have an account with a financial institution. It is standard to disclose a private, personal information profile 102 to the financial institution during the account application process. At step 104, the financial institution, which permitted an account opening, creates a personal log file in the financial institution back office establishes a withdraw/deposit mechanism, and issues personal checks and cards. Then financial account holder, whether it is a legal person 101 or a legal business, can perform deposit 105 or withdraw 106 transactions. Typical deposit transactions to a bank or a brokerage house 107 are made through either a direct/mailed deposit with a personalized deposit slip 109 or by submitting a check on one's name and disclosing one's account number. Another way of obtaining deposits is used by insurance 117 and credit card companies 115, which receive paid statements 119 from financial account holder. Checks 110, debit cards 112 or Graphical User Interfaces (GUI) over the Internet 113 are used by financial account holders for withdraw transactions with a bank or a brokerage house 108. The credit card 116 is a typical withdraw mechanism for withdraw transactions with credit card companies (whether they are banks like Visa and Master Card or not, like American Express). Another withdraw mechanism is used by financial account holders when dealing with insurance companies 118. A request for payment 120 is to be made in accordance with the insurance policy.
There are deficiencies in the deposit/withdraw transaction system described above related to privacy and security of the financial account holder and financial institution performing transactions including the following:
1) Direct and urgent deposit transactions can be hindered, if the financial account holder is located far away from the bank and its branches where the account resides. It should be possible to deposit to one's account via other financial institutions, without disclosing private personal information of financial account holders at other financial institution's intermediate service levels.
2) During depositing, bank tellers get access to the private personal information of the financial account holder. There are two issues here. Firstly, a teller can make mistakes altering personal and account balance information without any immediate financial institution back office CPU and dB control. In other words, each deposit transaction has a probability of mistakes, hurting the bank and the financial account holder. Secondly, the financial account holder may not like a bank teller to have access to his/her private personal information file during direct depositing. At this stage it would be beneficial, if financial account holder could decide him-/her-self whether this privilege should be given to the bank teller.
3) Insufficient theft and fraud protection during withdraw transactions with checks, credit, charge and debit cards or during electronic commerce financial transactions.
4) Private personal information is not protected and often intentionally or unintentionally misused by a party at the point of sale or bank tellers during withdraw transactions.
FIG. 1B illustrates a block diagram of a conventional system for performing buy/sell transactions. Once financial account holder 121, has made a buying decision 122 and applied to a party at the point of sale, the actual selling transaction is enabled through cash 124, credit cards 116, debit cards 112, checks 110 or electronic commerce 125. Though cash is handy for low value financial transactions, it is usually impractical for the bulk of mass financial transactions due to low cash amount on hand. All other financial transaction instruments except cash, such as credit cards 116, debit cards 112, electronic commerce 125 and checks 110 lead to either complete or partial disclosure of private personal information 127, and are therefore prone to private personal information misuse and fraudulent actions 128.
FIG. 2 illustrates a block diagram of a conventional system and method for performing authentication, authorization and accounting sessions during buy/sell transactions with a credit card, a charge card or a debit card. As illustrated in FIG. 1B and FIG. 2, once a financial account holder 121 has made a buying decision 122 and applied to a party at the point of sale, a point-of-sale (POS) device scans static information on a credit card and sends an authorization request to financial institution back office, specifying price (money transaction amount), to perform a withdraw transaction 205. The financial institution back office CPU checks whether there is enough money in the database under this account and if yes, and if the card is not marked in the database as lost, stolen or fraudulently used, authorizes the withdraw transaction 206 (it sends an authorization code to POS device). Steps 205 and 206 constitute the authorization stage 201 of the financial transaction. It is worthwhile to note that in the conventional financial transaction system with credit/debit cards, the authorization stage is performed prior to authentication and accounting stages of the financial transaction.
Once the transaction authorization is sent to a party at the point of sale 206, the first accounting step 202 is performed. The account under transaction is left with a locked sum of money to assure a payment to a party at the point of sale 207. The payment is made after deduction of the transaction fee to the card issuing bank and the discount rate fee to the acquiring bank or an independent sales organization, which provided the merchant status to a party at the point of sale. Once step 207 is completed, the financial institution back office is ready for another transaction of the same financial account holder, provided the requested spending limit is not exceeded.
Then if the credit card is signed, the signatures on the selling draft and on the card are visually compared at a party at the point of sale for off line financial transactions 208. If the card is not signed, identification documents are requested from financial account holder 209. Steps 208 and 209 are components of the authentication stage of financial transaction 203 for the conventional off line financial transaction system. It can be noted here that the conventional electronic commerce on line financial transaction system based on credit/debit card usage skips step 208, and instead enforces step 209, requiring quite wider disclosure, than in a case of off line financial transaction, of financial account holder private personal information. Then the final step of accounting stage 204 is performed. Step 210 includes the following: a party at the point of sale sends the selling draft inside the selling batch after trade hours to the acquiring bank (or an independent sales organization). The acquiring bank re-routes the respective part of the batch to the card issuing bank to unlock the payment and transfer it to a merchant account after deductions, specified in the merchant's agreement. Then the money is placed into a merchant account in few days.
The conventional financial transaction architecture based on credit/debit cards and shown in FIG. 2 has the following weaknesses, which the present invention addresses:
1) Authentication stage is de-coupled from financial institution back office CPU and dB, making it subjective, embarrassing, error and fraud prone.
2) Authorization stage is de-coupled from financial account holder for both on and off line financial transactions, making it especially dangerous for on line financial transactions (due to on line financial transaction latency, a number of unauthorized financial transactions may happen before financial account holder regains control on the account).
3) Private personal information leaks are possible on the Internet communication lines during electronic commerce sessions (browsing technology, TCP/IP protocols, PKI, SSL and other Internet technologies do not guarantee sufficient financial transaction security).
4) Accounting stage is de-coupled from financial account holder, keeping one at inconvenience during a series of buy/sell financial transactions.
5) A party at the point of sale may collect and analyze financial account holder private personal information, and market and sell it for profit. This leaves public at large unaware of privacy and confidentiality status of the data.
Present on line and off line financial transaction architectures have substantial security and privacy deficiencies at the authentication, authorization and accounting stages. It would be highly desirable to provide an improved system and method wherein consumers can perform financial transactions with financial institutions without privacy and security concerns. The present invention addresses these problems.